Gitblit est un outil de gestion de dépôt Git, à l’instar de Gitosis ou Gitolite. L’idée est de permettre de partager ses dépôts, gérer des droits d'accès, fournir des sauvegardes… tout en restant dans les murs de l’entreprise si nécessaire.
Pour les entreprises, justement, qui n’ont pas toujours de compétences Rails ou de culture des clefs SSH, Gitblit possède certains atouts. Au niveau administration, avec une application légère en Java, autonome ou hébergeable dans un Tomcat ou dans le Cloud.
Au niveau de la gestion des utilisateurs, Gitblit offre, au choix, des solutions généralement appréciées des entreprises : LDAP ou Active directory avec gestion des habilitations basée sur les groupes, Windows, PAM, Conteneur type Tomcat ou personnalisé. La gestion par clefs SSH sera apportée par la version 1.5.
Associé aux autres fonctionnalités plus courantes, Gitblit offre la possibilité de mettre en place un Github-like dans son entreprise.
Sommaire
- Fonctionnalités précédentes
- Nouveautés majeures apportées par la version 1.4.x
- Licence et Contribution
Fonctionnalités précédentes
Gestion des Hooks
Un mécanisme de Hook (ou Trigger) est accessible, permettant de scripter des actions lors d’un push. Ils se programment en Groovy et ont accès au cœur de l’application. Quelques lignes suffisent donc pour créer une interaction avec une intégration continue ou une gestion de ticket. Des exemples utilisables sont fournis, entre autres, avec Jenkins ou Redmine.
Un aspect intéressant, c’est qu’il est possible de définir des Hooks systématiquement exécutés (comme avec Subversion) pour une intégration avec Jenkins, mais également des Hooks activables à la demande et par projet dans l’interface. C’est le chef de projet qui choisit la gestion de tickets utilisée sur ce projet.
Fédération et réplication
Un système complet de fédération de serveurs est utilisable. Les objectifs possibles peuvent être, par exemple, d’avoir un miroir permanent sur un autre site afin de permettre une reprise d’activité rapide en cas d’incident (PRA).
Ou, autre cas d’entreprise pour les grosses structures, d’avoir un dépôt dans chaque site ou ville, consolidé au niveau national.
Divers
Quelques autres fonctionnalités intéressantes :
- possibilité de n’être qu’un simple visionneur de dépôt d’un autre service Git, comme Gitolite avec SSH, ou Gerrit ;
- une indexation Lucene pour faire des recherches performantes sur un ensemble de dépôts ;
- des menus personnalisables pour les clients Git utilisables dans l’entreprise ;
- une API JSON-RPC, qui sera d’ailleurs largement complétée avec la version 1.5, afin de permettre des workflows avancés, comme des acceptations partielles par Jenkins de pull-request.
Nouveautés majeures apportées par la version 1.4.x
Tickets
Une gestion de Tickets similaire à GitHub/BitBucket a été implémentée mais un peu différemment. Il n’y a pas de distinction entre un ticket et un pull request.
Chaque ticket peut avoir un ou plusieurs commit(s) lié(s) à une branche et il n’y a pas nécessité de créer plusieurs tickets pour différentes versions (forks) du même code.
Au niveau de Gitblit, la conception tourne autour de quelques principes :
- gestion simple pour tracer les actions ou les rapports d’utilisateurs ;
- chaque ticket peut contenir des commits partagés par un contributeur ;
- le ticket doit être la source canonique de commits lié au ticket (et non les commits d’un fork) ;
- les contributeurs supplémentaires d’un problème doivent pouvoir développer des ensembles de patches pour un ticket, et non seulement le créateur du ticket. Le ticket rassemble donc l’ensemble des contributions et non seulement une revue de code ;
- pas de perte d’historique entre le mainteneur ou contributeurs.
Gitblit a pris son inspiration depuis GitHub, BitBucket, and Gerrit. Les différents mécanismes techniques sous‐jacents ont été implémentés et testés avant de faire les choix définitifs.
Workflow de collaboration (pull-request)
Les pull requests à la manière de GitHub demandent le workflow suivant :
- forker le ProjetA en MonProjetA ;
- cloner MonProjetA sur le poste de travail ;
- créer MonProjetA_Clone:topic_branch et travailler sur la contribution ;
- faire un push MonProjetA_Clone:topic_branch upstream vers
MonProjetA:topic_branch
; - Ouvrir une pull request depuis MonProjetA:topic_branch vers
ProjetA:integration_branch
; - Le propriétaire de ProjetA fait un pull
MonProjetA:topic_branch
versProjetA:integration_branch
et inspecte la contribution ; - Le propriétaire de ProjetA fait enfin un push de la contribution fusionnée vers
ProjetA:integration_branch
.
Le flux avec Gitblit ressemble à ceci :
- cloner ProjetA ;
- créer
ProjetA_Clone:topic_branch
et travailler sur la contribution ; - faire un push
ProjetA_Clone:topic_branch upstream
versProjetA:refs/for/[new|id]
, - le propriétaire de ProjetA fait un fetch et un merge de la branche ticket/[id] ;
- le propriétaire de ProjetA fait un push de la fusion vers
ProjetA:integration_branch
.
Le workflow Gitblit supprime la conception à 4 dépôts de Github (canonique, copie de travail canonique, fork, & copie de travail du fork) au profit d'une à 3 dépôts (canonique, copie de travail canonique, copie de travail du clone).
La conséquence de l’implémentation de Gitblit, c’est que pour le travail d’une nouvelle fonctionnalité donnée, il y a harmonie entre un ticket, les commits dans une branche liée, la contribution à plusieurs sur cette branche, les revues de code (avec notes) et la fusion.
Au passage, on économise les ressources système d’un dépôt supplémentaire et d’une étape dans l’interface Web.
Licence et Contribution
Gitblit est sous licence Apache 2.0 et est développé pour l’instant sur Github. Les contributions sont appréciées, via le mécanisme du fork et pull-request.
Une traduction en français de l’interface est commencée sur le fork listé dans les liens, n’hésitez pas à y contribuer. L’objectif premier est d’avoir une traduction gardant le nom des commandes Git intact et, peut‐être ensuite, une autre plus « québécoise » traduisant intégralement tous les termes. Les gens choisiront.
Aller plus loin
- Site officiel (1014 clics)
- Demo de la prochaine version (534 clics)
- Fork Github pour la traduction française (95 clics)
- Screencast de fonctionnalités liées aux Tickets (126 clics)
# par rapport à Gitlab …
Posté par Dreammm . Évalué à 6.
Quels sont les avantages/inconvénients par rapport à Gitlab ?
[^] # Re: par rapport à Gitlab …
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
Je ne connais pas assez Gitlab pour te faire un diff fonctionnel complet, mais cela semble très très proche.
Quelques différences que je remarque tout de suite:
- Le système / administration / contribution: Gitlab est en Ruby, Gitblit en Java (et hooks en Groovy). La suite dépend des adminsys qui maintiendront derrière, ou de ceux qui écriront les hooks
- Gitlab est fait avec une société, donc certaines fonctionnalités comme les Groups LDAP ou les Hooks sont réservé à une version payante. Gitblit est purement communautaire, totalement gratuite, sur Github et contribution acceptés. Par contre pas de support société (forcement)
Rien que ces 2 points, sans prendre parti, peuvent faire pencher d'un coté ou de l'autre lors d'un choix.
[^] # Re: par rapport à Gitlab …
Posté par soltar . Évalué à 1.
Effectivement, rien que le point de la gestion des groupes LDAP en version payante par Gitlab me fait faire mon choix :)
Merci de cette courte analyse mais de grande valeur vu qu'on voit clairement ainsi quelques différences entre deux produits très similaires en description générale (grande vérole des produits à double license : on oublie trop souvent de dire que les points intéressants sont présents que dans la version payante)
[^] # Re: par rapport à Gitlab …
Posté par SauronDeMordor (site web personnel) . Évalué à 4.
pour avoir mis en place les 2,
la différence est que gitlab:
* c'est la misère à installer et maintenir (pb de ruby/version/upgrade).
* pas de système de package(enfin pas quand j ai essayé).
* pourrissage du système, ou gestion de plein de gem locale pas forcement stable sur la durée.
on peut dire qu il y a bundler, rvm,… mais pour une installation de prod, avec garantie de bon fonctionnement, j'achète pas.
avec gitblit, et bien c'est un jar, ou via tomcat,
* facile à gérer et maintenir.
* une doc qui marche.
* pas de prérequis impossible avec une distrib serveur un peu ancienne (on a pas tout en debian sid, ou RH7)
ensuite l intégration avec un AD, les tickets (depuis la 1.4), les settings dans un fichier de param lisible, ce n est que du bonheur.
à essayer et à adopter si on a besoin d un serveur git qui marche sans soucis.
[^] # Re: par rapport à Gitlab …
Posté par Anonyme . Évalué à 2.
gitlab, par rapport à ma première installation qui date de la version 5, s'est grandement amélioré. Et si les gems peuvent être un problème car installées à La RACHE®, aujourd’hui, j’oserais dire qu’il y a les conteneurs, voir même les chroot si on n’a pas comme objectif la sécurité ;)
La documentation est bien foutue, les guides d’upgrade sont foutrement terribles et faciles d’accès, donc changement de version de Ruby à part, c’est très simple et ça se préprod facilement ;)
# Gitolite
Posté par sifu . Évalué à 3.
Pour moi, cela semble bien différent de Gitolite qui se concentre sur la gestion des droits d'accès sur un ensemble de dépôts Git.
cf. http://gitolite.com/gitolite/why.html
# Petite revue
Posté par El Titi . Évalué à 3.
Si je saisis bien le fonctionnement de cet outil pour la gestion des tickets:
Lorsque l'on contribue à un projet en le "forkant", on pushe vers le dépôt de référence et c'est une convention de nommage qui permet d'isoler chaque contributeur, là où le fork de Github crée un clone à la volée sur le serveur.
Ensuite pour l'acceptation, l'intégrateur se contente de merger cette branche en local et de pusher sur la branche d référence.
Le dépôt de référence est donc suceptible d'être pollué par d'autres branches ce qui va à l'encontre de la philosophie du "pull request".
Pour ce qui est des fonctionnalité, hormis l'interface de gestion de ticket je préfère nettement SCM Manager
( http://www.scm-manager.org/ ) qui est très comparable en terme de fonctionnalité pour un gestionnaire de dépôt (full Java, integration LDAP, …)
Nous l'utilisons depuis 1 an et demi dans notre entreprise (une DSI). Il héberge plus de 800 dépôts et s'intègre très bien avec le reste de notre forge basée sur la suite Atlassian (JIRA/Bamboo/Crowd). Un plugin d'intégration à Crowd est fourni (annuaire Atlassian qui lui même référence l'annuaire AD de l'entreprise).
Il est maintenant très stable et supporte par ailleurs les pull request à la manière de Github et donc de façon cloisonnée.
Le seul inconvénient.
Dans JIRA les commits d'un ticket sont référencés dans l'onglet description alors que SCM Manager ne peut les afficher qu'en tant que commentaire. Mais c'est plutôt une limitation de JIRA que de SCM Manager.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.